Igor 🐱 Jirkov in ITMO.OpenSource

Евгений Кривошлыков

1. Код некоторых компонентов предпочтительно разрабатывать в приватных репозиториях, прежде чем опенсорсить, потому что от них зависит безопасность
2. Если компания хочет иметь возможность сделать бесплатную (и открытую) и коммерческую (закрытую) версию, и для неё это единственный способ выжить, то заставив компанию работать по GPL проиграют все.
3. Почему-то вы оперируете в парадигме, что корпорации только и ждут чтобы своровать чей-то открытый код и продать его за деньги, проэксплуатировав бедных программистов. На деле большинство софта сейчас делается радикально по-другому.
- почти любой продукт включает в себя огромное количество кода, не созданного внутри компании (в 80-е и 90-е было иначе)
- сами библиотеки имеют множество зависимостей, почти любой продукт зависит от огромного количества другого кода, который живет и развивается. В современных языках с пакетными менеджерами в экосистемах эта особенность только усиливается.
- таким образом, любой продукт находится в центре развесистой сетки зависимостей от независимо развивающихся библиотек. Скопировав себе чужую библиотеку вы не просто получаете решение кусочка своей проблемы, но и набираете технический долг: надо патчить уязвимости, баги, адаптировать код под обновленные зависимости. Сложность систем высока -- у вас нет столько программистов чтобы разбираться в каждой библиотеке, на ходу продолжать "воровать" изменения из апстрима нужной библиотеки и следить чтобы ваш продукт при этом не развалился. Выгоднее, например, дать денег разработчикам библиотеки, чтобы они адаптировали её под ваши нужды, при этом библиотека останется открытой.
- при этом качество кода часто не такое высокое, чтобы с ним вообще можно было взаимодействовать не переписав его кусок или не написав обертку (которая, опять же, органичнее всего пишется с помощью копипасты).

Поэтому для многих разработчиков библиотек есть смысл максимизировать удобство интеграции их кода чтобы максимизировать количество пользователей, MIT/Apache дают в этом наибольшую гибкость. Те, кто просто скопируют их код, попадают на крючок вышеописанных проблем в будущем (обновление, поддержка, адаптация под новые версии зависимостей и т.д.), и наиболее разумное решение для них -- по максимуму контрибутить в общий, открытый репозиторий кодом или иными ресурсами (потому что там сообща все пользователи библиотеки могут работать над качеством кода, и для каждого пользователя это получается дешевле -- economy of scale). Если нужны какие-то изменения/адаптация кода под конкретный продукт, делают публичный форк, который легче поддерживать в консистентном состоянии с апстримом.

Экономика разработки изменилась, и этически корректное решение теперь часто совпадает с экономически выгодным.

www.tg-me.com/jp/ITMO OpenSource/com.itmo_opensource/8996

edited  May 14 at 08:50

1. Код некоторых компонентов предпочтительно разрабатывать в приватных репозиториях, прежде чем опенсорсить, потому что от них зависит безопасность
2. Если компания хочет иметь возможность сделать бесплатную (и открытую) и коммерческую (закрытую) версию, и для неё это единственный способ выжить, то заставив компанию работать по GPL проиграют все.
3. Почему-то вы оперируете в парадигме, что корпорации только и ждут чтобы своровать чей-то открытый код и продать его за деньги, проэксплуатировав бедных программистов. На деле большинство софта сейчас делается радикально по-другому.
- почти любой продукт включает в себя огромное количество кода, не созданного внутри компании (в 80-е и 90-е было иначе)
- сами библиотеки имеют множество зависимостей, почти любой продукт зависит от огромного количества другого кода, который живет и развивается. В современных языках с пакетными менеджерами в экосистемах эта особенность только усиливается.
- таким образом, любой продукт находится в центре развесистой сетки зависимостей от независимо развивающихся библиотек. Скопировав себе чужую библиотеку вы не просто получаете решение кусочка своей проблемы, но и набираете технический долг: надо патчить уязвимости, баги, адаптировать код под обновленные зависимости. Сложность систем высока -- у вас нет столько программистов чтобы разбираться в каждой библиотеке, на ходу продолжать "воровать" изменения из апстрима нужной библиотеки и следить чтобы ваш продукт при этом не развалился. Выгоднее, например, дать денег разработчикам библиотеки, чтобы они адаптировали её под ваши нужды, при этом библиотека останется открытой.
- при этом качество кода часто не такое высокое, чтобы с ним вообще можно было взаимодействовать не переписав его кусок или не написав обертку (которая, опять же, органичнее всего пишется с помощью копипасты).

Поэтому для многих разработчиков библиотек есть смысл максимизировать удобство интеграции их кода чтобы максимизировать количество пользователей, MIT/Apache дают в этом наибольшую гибкость. Те, кто просто скопируют их код, попадают на крючок вышеописанных проблем в будущем (обновление, поддержка, адаптация под новые версии зависимостей и т.д.), и наиболее разумное решение для них -- по максимуму контрибутить в общий, открытый репозиторий кодом или иными ресурсами (потому что там сообща все пользователи библиотеки могут работать над качеством кода, и для каждого пользователя это получается дешевле -- economy of scale). Если нужны какие-то изменения/адаптация кода под конкретный продукт, делают публичный форк, который легче поддерживать в консистентном состоянии с апстримом.

Экономика разработки изменилась, и этически корректное решение теперь часто совпадает с экономически выгодным.

BY Igor 🐱 Jirkov in ITMO.OpenSource